IV.後端基礎操作
(哭啊,前天斷更了,想先整理30天初稿等這裡連載完再整理一次)
本來很想讓FHIR的概念知識湊到剛好1/3的篇幅,
但後來發現好像會塞不下只好寫到第八天,
今天要來談很簡單的RESTful API操作,
FHIR的設計訴求中,非常核心的一點就是RESTful API,
透過RESTful API的統一操作方式,讓所有裝置、
平台與應用程式都可以非常輕易的進行資料的交換,
那什麼是RESTful API操作,
RESTful API是一種API的實作風格,全稱Representational State Transfer,
中文稱「表現層狀態轉換」,在REST架構上,Client端與Server端的實作可各自獨立完成,彼此間的程式更改並不會影響到彼端的運作,只要雙方能夠共同維護相同的API接口與定義,就能保證兩方能夠處理請求。
在REST中,
Client發出Request告訴Server他所需要的操作,
而Server回傳Response給Client他所需求的回應,
一個Request中通常包含了Header與Body
Header:在Request中與需求相關的資料內容,下方又內含
HTTP Method Name:如POST, PUT等,定義所需求的類型
Path:資料的路徑URL
HTTP version number:如HTTP/1.1
Body:關於這則需求的主內容本文或主需求欄位
這樣聽起來有點抽象,下面逐一來說明上面各項分別的定義:
RESTful的好處是他利用著HTTP協定的關鍵詞,利用HTTP Method來作為API類型的分類,
其中常見的幾個:
以最概觀來看,REST的首項就是負責告訴使用者,
這個API代表的動作分類,使用者可以最初步的看到這個動作分類來知道這條API是搜尋、創建還是刪除。
Header
Header是Request中非屬於本文的周邊參數,包含Content Type, Origin等,能夠確保Client端與Server端
彼此在溝通前有一些共同的參數可以互傳,
Cotent Type指的是Body的資料型態,這被稱為MIME Type(Multipurpose Internet Mail Extensions, 多用途網際網路郵件擴展),包含資料的型別,通常的表示方法是Type/SubType,如application/pdf等
Path
Request中會包含應操作的資源路徑,概觀來看可以理解成API的URL,而該URL的後綴通常會填入關於操作的參數。
而一個Response會包含:Header、Body與Status Code
Status Code是HTTP狀態碼,如常見的404, 503等,
REST利用HTTP的狀態Code來描述Client與Server該次溝通的結果與狀態,
開發者能夠透過API文件上對應代碼的說明來知道該次溝通的結果。
以HTTP狀態碼來說共有三碼,第一碼代表基礎的狀態
1 = Informational message,某種訊息的傳達
2 = Success,成功執行API
3 = Redirect,表示API將此需求轉送至其他位址
4 = Client Error
5 = Server Error
以上是很概要的分類,詳細的定義仍需要檢視指定的API文件
大致知道RESTful API在幹嘛之後,這裡要讓大家使用Postman
https://www.postman.com/downloads/
Postman是一款後端常用的測試軟體,可以測試各個RESTful API的端口可以正常運作,
若使用Linux系統或Windows原生也可以使用curl指令,但Postman的GUI介面操作用起來比較直觀,因此本文主要會使用Postman來講解,實際選擇以個人偏好為準。
安裝可以選擇不登入,使用Lightweight Client即可,
打開Postman可以見到這樣的介面:
可以看到上方的欄位中,首先有HTTP Method可以選,預設是GET,
可以依照需要使用的API動作定義來選擇需要的型別
在動作與網址下方的條列中,
有Param、Authorization、Header、Body等欄位可以點開來使用,
針對個別的API設定再進行實際的輸入。
以輸入GET https://tw.yahoo.com 為例,當按下Send時,
Response會回傳yahoo的首頁HTML回來
事實上RESTful API作為一種大多數接口與服務使用的架構,
只要能夠使用HTTP協定的裝置或應用都能夠使用他,也因此奠定了強大的互通性。
實際的使用會放在FHIR Server互動,若讀者有興趣可上MDN了解REST
https://developer.mozilla.org/en-US/docs/Web/HTTP